Resolve manifest refs lazily to avoid OOM on large shards#26
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request refactors the FlatBuffer manifest parser to resolve chunk references lazily instead of materializing JavaScript objects for all references upfront. This change prevents out-of-memory (OOM) errors when handling large virtual shards. The ArrayManifest interface has been updated to support lazy resolution, and the binary search lookup has been adapted accordingly. Additionally, documentation was added to clarify the memory implications of the manifest cache size, and the test suite was updated to support the new lazy interface. There are no review comments, so I have no feedback to provide.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
1 participant
Reading one chunk materialized the array's whole manifest shard:
parseManifestbuilt aChunkRefobject per ref, even though a lookup only needs the one found by binary search. On fine-level virtual manifests (tens of millions of refs) this inflated the heap ~70× and OOM-crashed browser tabs and Node.Refs now stay in the FlatBuffer and resolve lazily:
findChunkRefprobes only each ref's coordinates and materializes the single match. For 1M synthetic refs, heap retained after a lookup drops from 345 MB to ~0.Note: the whole shard is still downloaded and decompressed; the cached manifest retains that buffer, so
maxManifestCacheSizebounds count, not bytes (now documented).Closes #24